home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970929-19971216 / 000194_news@newsmaster….columbia.edu _Wed Oct 29 03:55:58 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id DAA08575
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 29 Oct 1997 03:55:58 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id DAA25516
  7.     for kermit.misc@watsun; Wed, 29 Oct 1997 03:55:57 -0500 (EST)
  8. Path: news.columbia.edu!news.new-york.net!news-peer.gsl.net!news.gsl.net!gip.net!news.idt.net!dispose.news.demon.net!demon!news.demon.co.uk!demon!fangorn.demon.co.uk!news
  9. From: adrian@fangorn.demon.co.uk (Adrian Godwin)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Problem with TRANSMIT / Linux 2.0.27 / Redhat 4.1
  12. Date: 29 Oct 1997 00:51:36 -0000
  13. Organization: Adrian's rest home for middle-aged electronics
  14. Message-ID: <6361ao$b4j@fangorn.fangorn.demon.co.uk>
  15. NNTP-Posting-Host: localhost.fangorn.demon.co.uk
  16. X-NNTP-Posting-Host: fangorn.demon.co.uk [158.152.8.130]
  17. Lines: 98
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:7975
  19.  
  20.  
  21. I'm having some problems using the TRANSMIT command : the transmission
  22. stops just short of the end of the file. The amount lost depends on
  23. various factors (see below), but is generally just a few characters
  24. short. The behaviour isn't totally repeatable : if I send the same
  25. file 4 times, it might go OK once.
  26.  
  27.  
  28. I'm using :
  29.  
  30. Kermit 6.0.192 patch 18 (ckermit-6.0.192-7.i386.rpm from columbia)
  31. Linux 2.0.27 (Redhat 4.1 from Pacific HiTech CDROM)
  32.  
  33. I suppose I can't be totally sure of the reliability of the serial
  34. port, PC chipsets and UARTS being what they are. But it's the same 
  35. serial port I use for various jobs (including interactive connections
  36. to the same RS232 device, Kermit connections, a PPP link to the 
  37. internet and so on) and it seems to work reasonably well.
  38.  
  39.  
  40.  
  41. I've tried :
  42.  
  43. running Kermit -Y 
  44.     ( no difference from symtoms with standard startup script )
  45.  
  46. set file type { text / bin }
  47.     ( the number of characters lost varies slightly )
  48.  
  49. enabling local echo
  50.     ( the whole file is echoed to the screen, but not sent to the
  51.       line. There's another effect too : echo only works in binary 
  52.       mode, not text )
  53.  
  54. telnet instead of serial connection
  55.      ( the whole file appears to be sent over TCP. Another peculiarity
  56.        of local echo shows here : some of the echoing doesn't get 
  57.        flushed out until I do a connect command )
  58.  
  59. sending the file multiple times
  60.     ( the missing data never goes : i.e. it isn't just stuck
  61.       in the driver. 'Connect' doesn't flush it out, either )
  62.  
  63. monitoring the serial line
  64.     ( I'm checking the line with a protocol analyser : the data
  65.       really isn't sent, it's not just the other machine losing it )
  66.  
  67.  
  68.  
  69.  
  70. I haven't tried yet :
  71.  
  72. rebuilding Kermit from sources
  73.     ( this is probably the next thing I'll try )
  74.  
  75. A later linux
  76.     ( I know there's a later Redhat distribution )
  77.  
  78.  
  79. Any further suggestions gratefully received.
  80.  
  81.  
  82.  
  83. Here's the file I'm sending - it's delimited with LF and has a single
  84. LF after the last hex record. Either the last line or the penultimate
  85. line gets truncated. (Note to anyone familiar with intel hex : the 
  86. records for addresses 0140 and 0150 were deliberately removed to
  87. provoke the failure, since it's filesize dependent. I'm currently
  88. working around it by padding out the file with some junk that the
  89. receiver is known to ignore).
  90.  
  91.  
  92. :03000000020038C3
  93. :03000B000200CD23
  94. :100030000D0A50726F62650075810F1200B61200D2
  95. :10004000541200E2D2AF9000301200B19000301292
  96. :10005000011F80FE758DFD758BFF53890F4389202D
  97. :10006000438840759850438780D29922209807E5AD
  98. :1000700022B401F8D322C298E599C3223099FDC277
  99. :1000800099F59922C0E0C4118ED0E0118E22540F50
  100. :1000900024028380E7303132333435363738394102
  101. :1000A0004243444546740D117C740A117C22117C34
  102. :1000B000A3E49370F922758C00758A005389F0438C
  103. :1000C0008901D28C752164752201D2A922758AFF1B
  104. :1000D000758CDBD28CD52109752164D5220375225C
  105. :1000E000013285FF9074103124741031247413315F
  106. :1000F00024740D312474803124752000740431245B
  107. :10010000740E3124781474203127D8FA22B40A02EC
  108. :1001100080E3B40D1274807520008008310DA3E4D3
  109. :100120009370F922C380190520D33140E520B40A29
  110. :100130000474C080EFB41407752000748080E52239
  111. :1001600090316640FC22C296C297C294D294C29447
  112. :08017000A293D29485FF9022B6
  113. :00000001FF
  114.  
  115.  
  116. -adrian
  117.